SBOM generator#1682
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new SBOM generator plugin for mock, which is a great addition for improving software supply chain security. The implementation is comprehensive, capturing build environment details, package metadata, and dependencies in CycloneDX format. The documentation is also very detailed.
My review focuses on a few areas for improvement:
- There's a duplicated and likely outdated plugin file (
sbom_generator.py) in the root directory that should be removed. - The documentation has several inconsistencies with the implementation, particularly regarding the SBOM filename and default configuration values.
- The plugin code contains numerous
print()statements for debugging which should be replaced with proper logging. - There are some minor code style issues like imports inside functions and a hardcoded version number.
Overall, this is a solid contribution. Addressing these points will improve the quality and maintainability of the new plugin.
|
Can you add config option |
|
Please add release notes using https://github.com/rpm-software-management/mock/blob/main/docs/Release-Notes-New-Entry.md |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
There was a problem hiding this comment.
vcs-diff-lint found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.
|
Generally, it LGTM. And thanks for the contribution. But please wait for the full review after the holidays. |
|
I see more things there, but I will pause here. |
|
Thank you for the contribution! My first thought is that it’s quite a large addition. :) Would you mind moving the SBOM generator into a separate Python project? Alternatively, it could be a separate Mock sub-package providing a set of scripts for specific tasks, rather than one large code bundle. I believe this would make the project much more extensible (for example, when implementing SPDX). It also gives you more control over the code, as we won't have the capacity to give it the maintenance it requires. What if there were a script, for example sbom-generator, that was: a) copied into the build chroot (not the bootstrap chroot), and b) called by Mock? It would be nice to have a standalone script to generate component metadata for a given RPM, or SRPM file, or a specfile. Also, we already have tooling to list installed packages, so it would be great to reuse that instead of adding a new implementation. |
|
@azhuzhu can you give this a brief look? How much do we overlap with the syft generator? |
|
@praiskup I definitely don't have a problem maintaining this as an external python library that hooks a lighter weight mock plugin if thats the way you all want to go. Getting everyones feedback here has been priceless either way, since unless you use mock and understand just how complete of a picture it can present is a difficult to explain to someone who hasnt used it. Or seen how easy it is My roadmap for this project is to expand it much farther into source code inter-dependency analysis, across multiple programming languages based on the presentation I saw here: https://www.darpa.mil/research/programs/enhanced-sbom-for-optimized-software-sustainment |
There was a problem hiding this comment.
@azhuzhu can you give this a brief look? How much do we overlap with the syft generator?
Although both are to generate an SBOM for RPM, this plugin is different from the SBOM generator we have.
- This plugin is based on the mock buildroot for one SRPM with a target arch; Our approach is based on an SRPM with multiple arches. So this doesn't have an SRPM Component as the root.
- There are a list of sources and patches here as component items, but in our generator, we only record source archives as Ancestors of the SRPM component
- This plugin also parse runtime deps, which we didn't do.
- This plugin doesn't use other external tools (like
syft) to scan the content of (S)RPMS and merge the result in the output but we do. - Some details of the logic are different
|
SPX support option added with: general pylint cleanup also completed |
|
Can you please rebase? |
Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
This update includes: - CycloneDX 1.5 schema compliance - Build hardening metadata capture (FORTIFY, PIE, RELRO, etc.) - Improved dependency tracking and PURL/CPE support - Updated documentation for CycloneDX support - New default configuration options in config.py Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
… error Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
…cleanup Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
…e.now() Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
config_opts['sbom_generator_opts'] = {
'type': 'spdx',
}
Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
This moves the path conversion logic from the SBOM generator plugin to the core Buildroot class, as it is a general-purpose utility providing the reverse of make_chroot_path().
- Refactor sbom_generator to use native python-rpm bindings for metadata extraction - Fix NameError in _create_built_package_component when accessing sourcerpm - Improve forensic fidelity by moving signature metadata (date, algorithm) from aggregate signer-groups to individual toolchain components - Resolve merge conflicts with upstream/main in PLUGIN_LIST Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
- Use chroot-native RPM tools via doChroot for internal artifacts - Fix path mapping to bypass chroot for host-resident result files - Add regex-based fallback for spec parsing to handle legacy syntax - Consolidate imports and standardized toolchain PURLs Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
- move internal tests out of the project Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
atomicturtle
force-pushed
the
sbom_generator
branch
from
65deaee to
01b4db0
Compare
Keep both sbom_generator (local) and system_monitor (upstream) plugins.
5 participants
Pull Request: Add SBOM Generator Plugin
Summary
This PR adds a new plugin,
sbom_generator, which automatically generates a Software Bill of Materials (SBOM) for packages built with Mock.How it Works
The plugin runs as a
postbuildhook within the Mock lifecycle. It performs the following actions:Produced Artifacts
The plugin generates a single output file in the build results directory:
<name>-<version>-<release>.sbom: A valid CycloneDX 1.5 JSON file containing:Configuration
The following options are available in
config.pyto control the plugin behavior:generate_sbom(default:True): Enable or disable SBOM generation.include_file_components(default:True): Includes individual file entries and their hashes in the SBOM.include_file_dependencies(default:False): Maps explicit dependencies between files and their parent packages in the dependency graph.include_debug_files(default:False): Determines if debuginfo files are included in the manifests.include_man_pages(default:True): Determines if manual pages and documentation are included.include_source_dependencies(default:True): Establishes provenance by linking binary packages back to their source files (SRPMs/patches).include_toolchain_dependencies(default:False): Includes every package in the build environment as a dependency for full build-root auditing.Release Note
Added a new SBOM generator plugin. It creates a
<name>-<version>-<release>.sbomfile in the build results directory, documenting the package components, hashes, signatures, and build environment hardening status.